Field of the Invention
The present invention is generally related to enterprise value chains, and more particularly to a system and computer program for a global transaction manager in a federated value chain network.
Discussion of the Background
In an increasingly global economy, there is a need for computer networks to share information between computer applications and to better adapt to meet the needs of the business enterprise(s) and computer applications using such networks. Business enterprises of all types are faced with the challenge of managing and optimizing ever more complex supply chains. These supply chains, often called “value chains,” are characterized by a high degree of collaboration, cooperation, and interdependency between the enterprise and other entities or partners in the chain (e.g., raw materials producers, component manufacturers, distributors, and the like). The business goal of managing and optimizing a value chain is to minimize the costs incurred by all participants in the chain while maintaining a high level of customer service and maximizing profits. In order to achieve this goal, the enterprise strives to reduce the quantity of stored goods in the value chain, while minimizing opportunity loss by maintaining a sufficient inventory level to satisfy customer demand.
A typical value chain and/or supply chain may span multiple companies and/or entities and sometimes include hundreds or even thousands of companies and/or entities. In the prior art, each company and/or entity maintained its own separate value chain system. In particular, each company and/or entity maintained its own value chain network locally on its own computer systems, databases and computer programs associated with the value chain network. Even with so-called multi-tier or multi-echelon systems known in the prior art, each company and/or entity maintained its own multi-tier or multi-echelon system. The companies would then typically communicate with other companies in the value chain via exchange messages (typically EDI). These techniques are inherently flawed. According to the prior art, each company had to potentially integrate their own internal value chain with many if not all of the other companies in the value chain leading to n2 integrations, where ‘n’ is the number of companies in the value chain. Such an arrangement required additional time and expense in setting up and managing the value chain, and was highly coupled. Due to the high degree of coupling in the prior art, any changes in the value chain typically resulted in extensive modifications throughout the value chain. Further, due to the size and complexity of most value chains, schedule-driven and batch processing value chain management systems of the prior art often resulted in stale or out of date data being used. This led to expensive reconciliation and significantly limited the types of processes that could be executed. It was also difficult if not impossible to deploy new multi-company processes using the techniques known in the prior art. Finally, visibility beyond a company's immediate neighbors was problematic because multi-tier visibility was difficult if not impossible to obtain and to orchestrate.
For example, distributed databases are known in the prior art. A distributed database is a database that is under the control of a central database management system (DBMS) in which storage devices are not all attached to a common CPU. Distributed databases may instead be stored in multiple computers located in the same physical location or may be dispersed over a local area network (LAN) of interconnected computers. For numerous reasons, distributed databases are inherently flawed and not viable options for creating a federated value chain network, as described herein. For instance, distributed databases require all participants to use the same database (often the same version). They also require the database to be directly exposed instead of exposing the application programming interface (API) of the application. Directly exposing the database leads to a high degree of coupling. Any changes to a highly coupled database typically result in extensive modifications. Members of a value chain typically cannot independently upgrade using distributed databases because of this high degree of coupling, which makes distributed databases infeasible in practice as independently upgrading members in a federated network is an important practical requirement. Further, distributed databases do not have fault tolerance, resulting in issues like “split-brain.” Distributed databases also require proximity and may be dispersed over a LAN of interconnected computers, but are not practical to deploy over a wide area network (WAN). As such, distributed databases cannot be deployed in a global environment over a WAN. Finally, distributed databases are designed for “synchronous” environments and do not operate well in asynchronous environments.
Thus, there currently exist deficiencies associated with enterprise value chain replenishment, order and logistics planning and execution, and, in particular, with a global transaction manager in a federated value chain network.